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Abstract 

Design of large software systems requires rigorous application of 
software engineering methods covering all phases of the software pro- 
cess. Debugging during the early design phases is extremely impor- 
tant, because late bug-fixes are expensive. 

In this paper, we describe an approach which facilitates debugging 
of UML requirements and designs. The Unified Modeling Language 
(UML) is a set of notations for object-orient design of a software sys- 
tem. We have developed an algorithm which translates requirement 
specifications in the form of annotated sequence diagrams into struc- 
tured statecharts. This algorithm detects conflicts between sequence 
diagrams and inconsistencies in the domain knowledge. After synthe- 
sizing statecharts from sequence diagrams, these statecharts usually 
are subject to manual modification and refinement. By using the 
"backward" direction of our synthesis algorithm, we are able to map 
modifications made to the statechart back into the requirements (se- 
quence diagrams) and check for confiicts there. Fed back to the user 
conflicts detected by our algorithm are the basis for deductive-based 
debugging of requirements and domain theory in very early develop- 
ment stages. Our approach allows to generate explanations on why 
there is a conflict and which parts of the specifications are affected. 
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1 Introduction 



Size and complexity of software systems has increased tremendously. There- 
fore, the development of high-quality software requires rigorous application 
of sophisticated software engineering methods. One such method which has 



become very popular is the Unified Modeling Language. UML |]T2[ has been 
developed by the "three amigos" Booch, Jacobson, and Rumbaugh as a com- 
mon framework for designing and implementing object-oriented software. 
UML contains many different notations to describe the static and dynamic 
behavior of a system on all different levels and phases of the software design 
process. 

Although UML provides a common notational framework for require- 
ments and design, UML, as any other language, does not ehminate bugs and 
errors. These bugs must be found and fixed in order to end up with a cor- 
rectly working and reliable system. It is well known, that debugging a large 
software system is a critical issue and can be a major cost-driving factor. 
Changes which have to be applied to the system (e.g., to fix a bug) are be- 
coming substantially more expensive, the later they are detected (Figure p. 
When an error is detected early during the definition phase, its cost is rel- 
atively low, because it only influences the requirements definition. Bugfixes 
in a product already shipped can be up to 60-100 times more expensive [Rl. 
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Definition Development after Release 



Figure 1: Relative costs for changes/bugfixes on different stages (based on 
i)- 



Therefore, it is mandatory to start with debugging as early in the project 
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as possible. In this paper, we will discuss an approach which supports de- 
bugging of scenarios (more precisely UML sequence diagrams) with respect 
to given domain knowledge. This is done as a part of an algorithm |T^ 



which can synthesize UML statecharts from a number of sequence diagrams. 
This synthesis step can be seen as a transformation from requirements to 
system design. It does not only facilitate fast and justifiable design from 
requirements (sequence diagrams), but also substantially helps to debug the 
generated designs. Because sequence diagrams usually cover only parts of 
the system's intended behavior, the generated statecharts need to be refined 
and modified manually. By applying the synthesis algorithm in a "backward" 
way, the refined statechart can be checked against the requirements. Each 
conflict is reported to the user and indicates a bug. 

For practical applicability of any debugging aid, the presentation of the 
bug, its cause and effect is of major importance. In our approach, we rely on 
logic-based explanation technology: all conflicts correspond to failure in log- 
ical reasoning about sequence diagrams, statecharts, and domain knowledge. 
Ongoing work, as discussed in the conclusions, uses methods from automated 
deduction to point the user to the exact place where the conflict occurred 
and which parts of the models and specification are affected. 

This paper is organized as follows: Section 2 gives an overview of major 
UML notations and a typcial iterative software design process. Then we 
will describe how sequence diagrams are annotated for a justified synthesis 
of statecharts (Section 4). Based on this algorithm we discuss methods for 
debugging a sequence diagram and a synthesized statechart. In Section 7 we 
discuss future work and conclude. 

Throughout this paper, we will use one example to illustrate our ap- 
proach. The example concerns the interaction between an espresso vending 
machine and a user who is trying to obtain a cup of coffee. This example 



(based on the ATM example discussed in [p!3| , P) is rather small, yet com- 
plex enough to illustrate the main issues. The requirements presented here 
are typical scenarios for user interaction with the machine (e.g., inserting a 
coin, selecting the type of coffee the user wants, reaction on invalid choices, 
and pressing the cancel button). More details of the requirements will be 
discussed when the corresponding UML notations have been introduced. 
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2 UML 

The Unified Modeling Language is the result of an effort to bring together 
several different object-oriented software design methods. UML has been 
developed by Booch, Jacobson and Rumbaugh |T2[ and has gained wide- 



spread acceptance. A variety of tools support the development in UML; 
among them are Rhapsody |10|, Rational's Rose or Argo/UML 0. 



On the top-level, requirements are usually given in the form of use cases, 
describing goals for the user and system interactions. For more detail and 
refinement, UML contains three major groups of notations: class diagrams 
for describing the static structure, interaction diagrams for requirements, and 
state diagrams and activity diagrams for defining dynamic system behavior. 
Below, we will illustrate the notations which are important for our approach 
to debugging of UML designs. 



2.1 Software Development with UML 

Although no explicit development process is prescribed for UML, UML de- 
sign usually follows the steps of Inception, Elaboration, Construction, and 
Transition, used in an iterative manner. In this paper, we will not elaborate 
on the process model. For details, cf., e.g., The importance of support for 
debugging of UML designs on the level of sequence diagrams (requirements) , 
and statecharts becomes evident, when we look at a graphical representation 
of an iterative development process (Figure 0). The design starts by analyz- 
ing the (physical) process at the lower left part of the figure. The result of 
the analysis comprises the requirements (e.g., as a set of sequence diagrams), 
and knowledge about the domain (henceforth called domain theory). Based 
on these, a model of the system is developed, consisting of class diagrams, 
statecharts and activity diagrams. This model must now be implemented. 
Modern software engineering tools provide automatic code-generation (or at 
least support) for this step. Finally, the produced system must be verified 
against the physical process, and its performance tuned. 

Traditionally, the way to get a working system is simulation (process- 
requirements-model), and testing (requirements-model-system). Here, er- 
rors and bugs have to be found and removed. Within an iterative design 
process, these steps are performed over and over again, depicted by the cir- 
cular arcs. To keep these iterations fast (and thus cost-effective), powerful 
techniques for debugging requirements against domain knowledge, and models 
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against requirements are vital. Our approach supports this kind of debug- 
ging and it will be discussed in the next section, following a short description 
of the basic concepts of class diagrams, sequence diagrams, and statecharts. 




Process 



System 



Performance tuning/ 
-verification 



Figure 2: Iterative Design Process 



2.2 Class Diagram 

A class diagram is a notation for modeling the static structure of a system. 
It describes the classes in a system and the relationships between them. 
Figure |^ shows an example of a class diagram for our coffee-vending ma- 
chine example. In an object-oriented fashion, the main class (here "coffee 
machine") is broken down into sub-classes. The aggregation relation ( — O) 
shows when one class is part of another one. The generalization relation 
( — [>) shows when one class is an instance of another. For further details, 
see e.g., [ff2 



2.3 Statecharts 

Statecharts [|, |12|, are finite state machines extended with hierarchy and 
orthogonality. They allow a complex system to be expressed in a compact 
and elegant way. Figure ^ shows a simple example of a statechart. Nodes can 
either be simple nodes (Al, A2, A3, B, and C), or composite nodes (node A 
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Figure 3: A Class Diagram for the Coffee machine. 



in the figure) which themselves contain other statecharts. The initial node 
in a statechart is marked by •. Transitions between states have labels of the 
form e[c]/a. If event e occurs and guard c holds, then the transition may 
be selected to fire which results in action a being taken and a state change 
occurring. This behavior is extended in a natural way to handle composite 
nodes. 



2.4 Sequence Diagrams 

Scenarios describe concrete examples of the system's intended behavior. In 
UML scenarios can be expressed as sequence diagrams. A sequence diagram 
(SD) shows the interaction between objects of a system over time. The SD in 
Figure ^ is an example for interactions between the objects "User" , the user 
interface of the coffee machine ("Coffee-UI"), and the machine ("Control") 
itself. The vertical lines represent the time-line for the given object, defining 
the object's life during the interaction. Messages (like "Insert coin") are 
exchanged between the objects. Figure ^ is a different scenario for our coffee- 
machine. It describes an invalid selection by the user (e.g., choosing sugar 
and sweetener at the same time). 
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Figure 4: Example of a Statechart. 



3 Extending Sequence Diagrams 

The simplicity of sequence diagrams makes them suitable for expressing re- 
quirements as they can be easily understood by customers, requirements 
engineers and software developers alike. Unfortunately, the lack of semantic 
content in sequence diagrams makes them ambiguous and therefore difficult 
to interpret. Let us assume that in our example, there exists an additional 
sequence diagram, SDO, identical to SDl in Figure |^ except that there are 
two "Insert coins" messages adjacent to each other. There are three possible 
ways to interpret the conjunction of the two SDs — either a cup of coffee costs 
one or two coins (ridiculous!), or it costs just one coin, in which case SDO is 
incorrect. The other case (two coins needed) invalidates SDl. In practice, 
such ambiguities are often resolved by examining the informal requirements 
documentation but, in some cases, ambiguities may go undetected leading to 
costly software errors. 

For the automatic generation of (conflict-free) designs, such documents 
are usually too informal. On the other hand, the need to provide a full 
formal domain theory containing all semantic information is clearly too much 
a burden for the designer and thus not acceptable in practice. 

Our approach allows for a compromise: the user can annotate messages in 
a sequence diagram with a pre/post-condition style specification expressed in 
OCL, UML's logic-based specification and constraint language. For success- 
ful confiict detection (and statechart synthesis), only a small percentage of 
messages need to be annotated at all. This specifications should include the 
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Figure 5: Interaction with a coffee 
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Figure 6: Another interaction with a 
coffee vending machine (SD2). 



declaration of global state variables, where a state variable represents some 
important aspect of the system, e.g., whether or not a coin is in the coffee- 
vending machine. Pre- and post-conditions should then include references to 
those variables. Our experience with the case studies carried out so far (see 
Conclusions) is that the state variables and their data types usually directly 
"fall out" from the class diagram. Note that not every message needs to be 
given a specification, although, clearly, the more semantic information that 
is supplied, the better the quality of the conflict detection. Currently, our 
algorithm only exploits constraints of the form var = value, but there may 
be something to be gained from reasoning about other constraints using an 
automated theorem prover, e.g., ^ or constraint solving techniques. 

Fig. 1^ gives specifications for selected messages in our coffee- machine 
example. Here, the state variables are the boolean variables CoinlnMachine , 
CoinlnReturnSlot , Cof f eeTypeSelected, the variable Coin reflecting the 
number of coins in the machine (0, or 1), and SelectedCof f eeType. In order 
to talk about all values of the state variables at a given point, we use the 
notion of a state vector. This is a vector of values of the state variables. In 
our example, the state vector has the following form: 

<CoinInMachine" , CoinlnReturnSlot", Cof f eeTypeSelected" , 
Coin", SelectedCof feeType"> 
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The notation far" extends the possible value for a state variable by an 
undetermined value, denoted by a "?", i.e., var^ G Dom{yar) U {?}. For use 
with our algorithm, we will annotate each message of a sequence diagram 
with a statevector where the values of the state variables are determined by 
the algorithm described below. 

4 Automatic Synthesis of Statecharts from 
Sequence Diagrams 

The framework for debugging UML designs is based upon an algorithm for 
automatic synthesis of statecharts from sequence diagrams and a domain the- 
ory [|l3l. The process to convert a number of SDs into a structured statechart 
consists of several steps: in the first step, each SD is annotated and conflicts 
between the SD and the domain theory (and hence, other SDs) are detected 
and reported to the user. Then, a statechart for each of the objects in the 
SD is generated; and all statecharts for an object are merged into a single 
statechart. The final step of the synthesis introduces hierarchy by grouping 
nodes into composite nodes, thus enhancing readability. In this paper, we 
are only concerned with the first, conflict detection part (as a basis for de- 
bugging), and the final result, the statechart. For details on the algorithm 
see H. 

There are two kinds of constraints imposed on a sequence diagram: con- 
straints on the state vector given by the OCL specification, and constraints 
on the ordering of messages given by the SD itself. These constraints must be 
solved and arising conflicts be reported to the user. More formally, the pro- 
cess of conflict detection can be written as follows. An annotated sequence 
diagram is a sequence of messages mi, ... , with 

pre mi^ post pre "V-i post pre "t^, ^post /-in 

where the sf^*^, '^^ are the state vectors immediately before and after mes- 
sage rrti is being sent. Si will be used to denote either sf^*^ or ^[j] 
denotes the element at position j in sf^^ (similarly for sf°'^^). 

In the first step of the synthesis process, we assign values to the variables 
in the state vectors as shown in Figure The variable instantiations of 
the initial state vectors are obtained directly from the message specifications 
(lines 1,2): if message mj assigns a value y to a variable of the state vector in 
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Figure 7: Domain theory for messages in the coffee-machine example. 
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Input. An annotated SD 

Output. A SD with extended annotations 

1 for each message rrii do 

2 if rrii has a precond Vj = y then sf'''^[j] := y else ^[j] := ? fi 

3 if rrii has a postcond = y then ''^[j] := y else ''^[j] := ? fi 

4 for each state vector Sk do 

5 if there is some Si ^ Sk and some unifier (p with (f){Sk) = (piSi) then 

6 unify Sk and Si; 

7 propagate instantiations with frame axiom: 

8 foreach j, i with i > 0: if sf'^^[j] = ? then sf''^[j] := sf^i*[j] fi 

9 ^jr'ij] = ? then sr\j] := ^r[j] fi 

10 if there is some i,j with sf°^\j] 7^ then 

11 Report Confiict; 

12 break; 



Figure 8: Extending the state vector annotations. 



its pre- or post-condition, then this variable assignment is used. Otherwise, 
the variable in the state vector is set to an undetermined value ?. Since each 
message is specified independently, the initial state vectors will contain a lot 
of unknown values. Most (but not all) of these can be given a value in one 
of two ways: two state vectors, Sk and Si {k I), are considered the same if 
they are unifiable (line 6). This means that there exists a variable assignment 
such that 4>{Sk) = 4>{Si). This situation indicates a potential loop within 
a SD. The second means for assigning values to variables is the application 
of the frame axiom (lines 8,9), i.e., we can assign unknown variables of a 
pre-condition with the value from the preceeding post-condition, and vice 
versa. This means that values of state variables are propagated as long as 
they are not changed by a specific pre- or post-condition. This also assumes 
that there are no hidden side-effects between messages. 

A confiict (line 11) is detected and reported if the state vector immediately 
following a message and the state vector immediately preceding the next 
message differ. 

Example. Let us consider how this algorithm operates on the first few 
messages of SDl from Figure ^ When annotating the first message ( "Display 
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Ready Light"), we obtain the following state vector on the side of the user- 
interface: Si = <F,F, ?,?,?>. The values of the first two state variables 
are determined by the message's pre-condition in the domain theory. The 
state- vector 5*2 on the receiving side of our message only consists of "?" . As 
a pre-condition for the message "Insert coin" we have CoinlnMachine = F. 
Thus we have 5*3 = <F ,?,?,? ,?> as the state vector. All other messages 
in SDl are annotated in a similar way. Now, our algorithm (lines 4-12) 
tries to unify state vectors and propagate the variable assignments. In our 
case, the attempt to unify 5*2 with 5*3 would assign the value F to the first 
variable in 5*2, yielding 5*2 = <F, ?,?,?,?>. Now, both state vectors are 
equal. Then, variable values are propagated using the frame axiom. In our 
case, we can propagate the value of CoinlnReturnSlot = F (from Si) into 
5*2 and S3, because the domain theory does not prescribe specific values of 
this state variable at these messages. Hence, its current value F can be used 
in the other state vectors, finally yielding 5*2 = 5*3 = <F,F, ?,?,?>. After 
performing all unification and propagation steps, we obtain an annotated 
sequence diagram as shown in Figure ^j. The confiict indicated there will be 
discussed in the next section. 



5 Debugging a Sequence Diagram 

The algorithm from the previous section detects confiicts of a SD with the 
domain theory (and thus with other sequence diagrams). Any such confiict 
which is detected corresponds to a bug which needs to be fixed. The bug can 
be in the sequence diagrams, which means that one or more sequences of ac- 
tions are not compatible with the domain theory, and henceforth with other 
SDs. Such a situation often occurs when sequence diagrams and domain the- 
ory for a large system are developed by different requirements engineers. Our 
algorithm is capable of directly pointing to the location where the conflict 
with the domain theory occurs. The respective message, together with the 
instantiated pre- and post-conditions, as well as the required state vector val- 
ues are displayed. This feature allows to easily debug the sequence diagram. 
Of course, the error could be in the domain theory instead. For example, one 
designer could have set up pre- or post-conditions which are too restrictive 
to be applicable for scenarios, specifled by other designers. In that case, the 
domain theory must be debugged and modifled. Our algorithm can also pro- 
vide substantial support here, because it is able to display the exact location 
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where the conflicting state variables have been instantiated. Especially in 
long sequence diagrams the place where a state variable is instantiated and 
the place where the conflict occurs can be far apart. The current version of 
our algorithm provides only rudimentary feed-back as demonstrated in the 
example below. Future work (which also allows richer OCL constructs to 
be used) requires more elaborate, human-readable descriptions of the error 
trace. Automated theorem provers and work on proof presentation, like the 
ILF system p|, || will be used for that purpose. Such a system will not 
only explain the possible reasons for a conflict, but can also give (heuristics- 
driven) hints to the user on how to flx the problem. 

Example. The following example shows, how conflict detection can be used 
for debugging: Figure |^ shows SDl from Figure ^ after the state vectors have 
been extended by our algorithm of Figure ^. Our procedure has detected a 
conflict with the domain theory. As an output it provides the messages and 
state vectors which are involved in the conflict: 

Conflict in SDl: Object Coffee-UI 
statevector after "Insert coin" = <T,F,T, 1 ,none> [Msg 2] 

statevector before "Request Selection" = <T,F,F, 1 ,none> [Msg 3] 
conflict in variable "Cof f eeTypeSelected" 
conflict occurred as consequence of unification of 
statevector after "Display Ready Light" = <F,F,T,0,none> [Msg 1] 
statevector after "Display Ready Light" = <F,F,T,0,none> [Msg 11] 
statevector after "Take coin" = <F,F,T,0,none> [Msg 10] 

This arises because state vectors SVl (state vector before "Display Ready 
Light") and SV2 (after "Take coin") are unifled (Figure 9 shows the instan- 
tiations of the vectors after uniflcation). This corresponds to the fact that 
the coffee machine returns to its initial state after "Take coin" is executed. 
The state vectors tell us that there is a potential loop at this point. A second 
execution of this loop causes the state variable "Coffee TypeSelected" to true, 
when the system asks for a selection. However, the domain theory tells us 
that this variable must be false as a pre-condition of the "Request Selection" 
message. Hence, there is a conflict, which represents the fact that the de- 
veloper probably did not account for the loop when designing the domain 
theory. 

The user must now decide on a resolution of this conflict — i.e., to debug 
this situation. The user either 
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Figure 9: Sequence Diagram SDl with extended annotations. A conflict has 
occurred. 

• can tell the system that the loop is not possible, in which case the unifier 
that detected the loop is discarded. This amounts to modifying the 
annotated sequence diagram (by restricting possible interpretations). 
The user can 

• modify the sequence diagram at some other point, e.g., by adding mes- 
sages; or 

• modify the domain theory. In our example, the action taken might 
be that the domain theory is updated by giving "Release coin" the 
additional postcondition Cof f eeTypeSelected = false. This extra 
post-condition resets the value of the variable (i.e., the selection) when 
the user is asked to remove the coin. The position of the change has 
been obtained by systematically going backwards from SV2. Although 
possible locations are automatically given by the system, the decision 
where to fix the bug ( at "Release coin" or at "Take coin") must be 
made by the user. Here, the second possibility was chosen, because the 
specification for that message modified a state variable which is related 
to the variable which caused the conflict. 
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6 Debugging a Synthesized Statechart 

When the statechart synthesis algorithm successfully terminates, it has gen- 
erated a human-readable, hierarchically structured statechart, reflecting the 
information contained in the SDs and the domain theory. In general, how- 
ever, sequence diagrams usually describe only parts of the intended dynamic 
behavior of a system. Therefore, the generated statechart can only be a skele- 
ton rather than a full-fledged system design. Thus, the designer usually will 
extend, refine, and modify the resulting statechart manually. Our approach 
takes this into account by generating a well structured, human-readable stat- 
echart which facilitates manual refinement and modification. 

However, these manual actions can be sources of errors which will have 
to be found and removed from the design. In the following, we describe two 
approaches, addressing this problem. 

6.1 Classical Debugging 

The traditional way to find bugs in a statechart is to run simulations and large 
numbers of test cases. Most commercial tools for statecharts, hke Betterstate, 
Statemate, or Rhapsody support these techniques. Some tools also provide 
more advanced means for analysis, like detection of deadlocks, dead branches, 
non-deterministic choices, or even model checking for proving more elaborate 
properties. In this paper, we will not discuss these techniques. 

6.2 Debugging w.r.t. Requirements 

Whenever a design (in our case the statechart) is modified, care must be 
taken that all requirements specifications are still met, or that an appro- 
priate update is made. Traditionally, this is done manually by updating 
the requirements document (if it is done at all). Bugs are usually not de- 
tected (and not even searched for) until the finished implementation is tested. 
Thereby, late detection of bugs leads to increased costs. By considering the 
"reverse" direction of our synthesis algorithm, we arc able to 

• check that all sequence diagrams are still valid, i.e., that they represent 
a possible sequence of events and actions of the system 

• detect confiicts between the current design (statechart) and one or more 
SDs, and 
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• detect inconsistencies with respect to the domain theory. 

The basic principle of that technique is that we take one sequence diagram 
after the other, together with the domain theory, and check if that sequence of 
messages is a possible execution sequence in the given statechart. Here again 
we use logic-based techniques, similar to those described above (unification 
of state vectors, value propagation with the frame axiom). An inconsistency 
between the (modified) statechart and the SD indicates a bug (in the SD 
or SC). By successively applying patches to the SD (by removing or adding 
messages to the SD) the algorithm searches for possible ways to obtain an 
updated and consistent SD. Since in general more than one possible fix for 
an inconsistency exists, we perform an iterative deepening search resulting 
in a solution with the fewest modifications to the sequence diagram. We are 
aiming to extend this search by applying heuristics to select "good" fixes. 

Here again, the form of feed-back to the user is of major importance. We 
are envisioning that the system can update the requirements and provide 
explanations for conflicts in a similar way as described above. 



Example. The statechart in Figure |10| has been refined. The transition 
between N2 and has been extended in such a way that first event 62, then 
63 with action 03 has to occur before the state is reached. The original 
statechart has been generated from a sequence diagram as shown on the 
right-hand side of Fig. 10. The modification of the statechart is propagated 
back to the sequence diagrams where the change is clearly marked. In this 
example, the extension could be made without causing a conflict. However, 
it is advisable for the designer and/or the requirements engineer to carefully 
observe these changes in order to make sure that these modified requirements 
still meet the original intended system behavior. 



7 Future Work and Conclusions 

We have presented a method for debugging UML sequence diagrams and 
statecharts during early stages in the software development process. Based on 
an algorithm, designed for justified synthesis of statecharts, we have identified 
two points where conflicts (as a basis for debugging) can be detected: during 
extending the annotations of a SD (conflicts w.r.t. the domain theory), and 
updating of sequence diagrams based upon a refined or modified statechart. 



The algorithm which is described in |T3[ has been implemented in Java 



and has been used for several smaller case studies in the area of object- 
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Object 1 Oi.J<s<=t2 Object 1 




Figure 10: Statechart with manual refinement (the removed transition is 
shown as a dashed hne, the new elements are bold), and the sequence diagram 
as updated by our algorithm (right). 



oriented systems, user interfaces, and agent-based systems |Tl|]. Current 
work on this part include integration this algorithm into a commercial UML 
tool (MagicDraw). Currently we are extending our synthesis algorithm to 
provide the debugging facilities described in this paper. Future work will 
mainly focus on integrating and extending explanation technology into our 
system. 

Debugging large designs with lengthy and complex domain theories vitally 
depends upon an elaborate way of providing feed-back to the user. Starting 
from the basic information about a conflict (i.e., a failed unification), we will 
use theorem proving techniques of abduction and counter-example generation 
to provide as much feed-back as possible on where the bug might be, and how 
to fix the problem|5 These techniques will be combined with tools capable of 
presenting a logic statement in human- readable, problem- specific way (e.g., 
ILF 0, 0). Only, if debugging feedback can be given in the notation of the 
engineering domain rather than in some logic framework, such debugging 
aids will be accepted in practice. 

It is believed that UML (and tools based upon this notation) will have 
a substantial impact on how software development is made. By providing 
techniques which do not only facilitate design by synthesis, but also provide 
powerful means to debug requirements and designs in early stages we are able 
to contribute to tools which are useful in design of large software systems. 



^ This problem essentially is equivalent to finding which hypotheses are missing or 
wrong when a conjecture cannot be proven valid. 
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